home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-mhsds-mhsprofile-03.txt < prev    next >
Text File  |  1993-07-08  |  6KB  |  311 lines
  1.  
  2.  
  3.  
  4. Network Working                                             S.E. Kille
  5. Group                                                 ISODE Consortium
  6. INTERNET-DRAFT                                               July 1993
  7.                                                 Expires:  January 1994
  8.  
  9.               A simple profile for MHS use of Directory
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15. This document is an Internet Draft.  Internet Drafts are working
  16. documents of the Internet Engineering Task Force (IETF), its Areas,
  17. and its Working Groups.  Note that other groups may also distribute
  18. working documents as Internet Drafts.
  19. Internet Drafts are draft documents valid for a maximum of six months.
  20. Internet Drafts may be updated, replaced, or obsoleted by other
  21. documents at any time.  It is not appropriate to use Internet Drafts
  22. as reference material or to cite them other than as a ``working
  23. draft'' or ``work in progress.''
  24. Please check the I-D abstract listing contained in each Internet Draft
  25. directory to learn the current status of this or any other Internet
  26. Draft.
  27.  
  28. Abstract
  29. The document ``MHS Use of Directory to support MHS Routing'' describes
  30. a comprehensive approach to MHS use of directory to support routing
  31. [1].  This document defines a strict subset of this document, which is
  32. intended to solve the most pressing problems.  It also defines a
  33. practical first step for implementation, such that this subset can be
  34. deployed prior to fuller implementation.
  35. This document does not repeat information in the other document.
  36. Duplication would only lead to the possibility of inconsistency.
  37.  
  38.  
  39. WARNING: This document must be read in the contex of the document it
  40.     profiles.  It is meaningless as a standalone document.
  41.  
  42. This draft document will be submitted to the RFC editor as a protocol
  43. standard.  Distribution of this memo is unlimited.  Please send
  44. comments to the author or to the discussion group
  45. <mhs-ds@mercury.udev.cdc.com>.
  46.  
  47.  
  48.  
  49.  
  50. INTERNET--DRAFT       Profile for MHS use of Directory       July 1993
  51.  
  52.  
  53. 1  Service Goals
  54.  
  55. The following goals are identified:
  56.  
  57.  
  58.  o  No routing table configuration for simple MTAs in a PRMD (WEPs and
  59.     gateways may do manual things).
  60.  
  61.  o  Single entry configuration for most sites.
  62.  
  63.  o  Do not replace function that is working reasonably well using
  64.     existing approaches.
  65.  
  66.  o  Ignore issues which are not yet operational concerns.  These can
  67.     be handled by the full specification in due course.
  68.  
  69.  
  70. 2  Approach
  71.  
  72. The approach to routing is to use the single routing tree associated
  73. with the open community.  MTAs will reference this tree.  Simple MTAs
  74. need only do this, plus ad hoc configuration to route to a suitable
  75. MTA with a fuller manual configuration (e.g., a WEP). This document
  76. goes through section by section, referencing the full document, noting
  77. what support is needed.
  78.  
  79.  
  80. 3  Profile
  81.  
  82. 3.1  General Table Handling
  83.  
  84.  
  85. Support for subtrees, but not flat tables is needed.
  86.  
  87. 3.2  O/R Address Hierarchy
  88.  
  89.  
  90. Support for all attributes is needed, except:
  91.  
  92. mHSX121
  93.  
  94. mHSDomainDefinedAttribute
  95.  
  96.  
  97.  
  98. Kille                                  Expires:  January 1994   Page 1
  99.  
  100.  
  101.  
  102.  
  103. INTERNET--DRAFT       Profile for MHS use of Directory       July 1993
  104.  
  105.  
  106. 3.3  Local Addresses
  107.  
  108. This is supported.
  109.  
  110.  
  111. 3.4  MTA Naming
  112.  
  113. All MTAs are named within the O/R Address tree.  The attributes which
  114. must be supported are:
  115.  
  116. responderAuthenticationRequirements
  117.  
  118. transportCommunity
  119.  
  120. remotePresentationAddress
  121.  
  122.  
  123. 3.5  Routing Trees
  124.  
  125. Only the single open community routing tree must be used.  A variant
  126. on this profile might relax this restriction, perhaps to support a
  127. small number of routing trees.  This relaxation should be noted in any
  128. statment referencing this specification.
  129.  
  130.  
  131. 3.6  Routing Information
  132.  
  133. The following attributes are used:
  134.  
  135.  
  136.  o  authoritativeAddress
  137.  
  138.  o  mTAInfo
  139.  
  140. Routing action is always the default.
  141.  
  142.  
  143. 3.7  Indirect Connectivity
  144.  
  145. This is not used.
  146.  
  147.  
  148.  
  149.  
  150.  
  151. Kille                                  Expires:  January 1994   Page 2
  152.  
  153.  
  154.  
  155.  
  156. INTERNET--DRAFT       Profile for MHS use of Directory       July 1993
  157.  
  158.  
  159. 3.8  Protocol Mismatches
  160.  
  161. The transport community approach is used.
  162.  
  163.  
  164. 3.9  Supported Protocols
  165.  
  166. This approach is used, but only P1(88) and P1(84) are considered.
  167.  
  168. 3.10  Capability Restrictions
  169.  
  170.  
  171. These are not handled.
  172.  
  173. 3.11  Pulling Messages
  174.  
  175.  
  176. This is not done.
  177.  
  178. 3.12  Authentication
  179.  
  180.  
  181. For 1988 usage, the distinguished name is used to identify the remote
  182. MTA. Authentication will be by network address.  Password will always
  183. be a zero length OCTET STRING.
  184. For 1984 usage, no authentication is done.
  185. The attribute must be supported, but only the
  186. responderAuthenticationRequirements attribute is used.  For MTAs
  187. following this specification, the following values must be set if
  188. bilateral-agreement-needed is false.
  189.  
  190.  
  191. mta-name-present true
  192.  
  193. aet-present true
  194.  
  195. aet-valid true
  196.  
  197. network-address true
  198.  
  199. simple-authentication false
  200.  
  201. strong-authentication false
  202.  
  203.  
  204. Kille                                  Expires:  January 1994   Page 3
  205.  
  206.  
  207.  
  208.  
  209. INTERNET--DRAFT       Profile for MHS use of Directory       July 1993
  210.  
  211.  
  212. If bilateral-agreement-needed is true, there are no restrictions on
  213. value.  Where a WEP uses this scheme, information on the bilateral
  214. agreement will be determined locally (by private means).
  215. The remotePresentationAddress attribute will always be present.
  216.  
  217.  
  218. 3.13  Policy
  219.  
  220. Policy will not be used.
  221.  
  222. 3.14  Protocol Extensions
  223.  
  224.  
  225. These will not be used.
  226.  
  227. 3.15  Format Conversion
  228.  
  229.  
  230. All issues relating to format conversion will be ignored.
  231.  
  232. 3.16  RFC 822 Support
  233.  
  234.  
  235. There is no support for RFC 822 or RFC 822/X.400 mappings by use of
  236. directory.
  237.  
  238. 3.17  Distribution Lists
  239.  
  240. This will not be supported.
  241.  
  242.  
  243. 3.18  Redirects
  244.  
  245. Not supported.
  246.  
  247.  
  248. 3.19  Bad Addresses
  249.  
  250. The mechanisms will not be supported.
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257. Kille                                  Expires:  January 1994   Page 4
  258.  
  259.  
  260.  
  261.  
  262. INTERNET--DRAFT       Profile for MHS use of Directory       July 1993
  263.  
  264.  
  265. References
  266.  
  267. [1] S.E. Kille. MHS use of the directory to support MHS routing, July
  268.     1993. Internet Draft.
  269.  
  270.  
  271. 4  Security Considerations
  272.  
  273. Security considerations are not discussed in this INTERNET--DRAFT .
  274.  
  275.  
  276. 5  Author's Address
  277.  
  278.     Steve Kille
  279.     ISODE Consortium
  280.     PO Box 505
  281.     London
  282.     SW11 1DX
  283.     England
  284.  
  285.  
  286.     Phone:  +44-71-223-4062
  287.  
  288.     EMail:  S.Kille@ISODE.COM
  289.  
  290.  
  291.     DN: CN=Steve Kille,
  292.     O=ISODE Consortium, C=GB
  293.  
  294.     UFN: S. Kille, ISODE Consortium, GB
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310. Kille                                  Expires:  January 1994   Page 5
  311.